We should display the final state of the swap until the user acknowledges it.

We should move the "cancel timeline" from the "history" page to the "swaps" page and hide it somewhat (make it expandable).

Issue:

run_exclusive_initiation releases the initiation lock at swap_manager.rs:642 before the lock-tx is broadcast. UTXO selection happens inside the spawned task (TxLock::new → wallet.send_to_address); the wallet mutex is method-level, so two concurrent buy_xmr calls can build PSBTs from the same UTXOs.

The interaction with the Watcher needs to be updated. The watcher still does in-line cancel_and_refund but should use the swap manager now. At least prevent the swap manager from spawning another state machine while the watcher is refunding

The interaction with the Watcher needs to be updated. The watcher still does in-line cancel_and_refund but should use the swap manager now. At least prevent the swap manager from spawning another state machine while the watcher is refunding

Yes you are right but the whole watcher should become redundant anyway... It should not be required if the state machine is properly working. The watcher should be abolished at some point.

I have 2 swaps where I had to do the XMR redeem manually which are now always automatically resumed - and keep failing. There needs to be a solution to this. Some kind of manually marking swaps as "do not resume" which is persisted across restarts.

Apart from that, I think we should change "Suspend" in the GUI to something like "Stop" or "Halt".

I have 2 swaps where I had to do the XMR redeem manually which are now always automatically resumed - and keep failing. There needs to be a solution to this. Some kind of manully marking swaps as "do not resume" which is persisted across restarts.

Apart from that, I think we should change "Suspend" in the GUI to something like "Stop" or "Halt".

"Stop" or "Halt" seems like this actually stop the timelocks from counting down or does something on a protocol level. I dont see them being clearer than "suspend".

"Stop" or "Halt" seems like this actually stop the timelocks from counting down or does something on a protocol level. I dont see them being clearer than "suspend".

Suspend has the same issue, except I have a much harder time imagining what "suspend" means. It's technical jargon.
We need to warn anyway that this doesn't stop the swap / refund window from progressing.

I'll remove the watcher.

What do you propose for the manually-finished-swap problem? We could just add a new db table with columns like swap_id, should_not_resume.

I'll remove the watcher.

What do you propose for the manually-finished-swap problem? We could just add a new db table with columns like swap_id, should_not_resume.

We could also bundle it with #932

Not sure if removing the watcher is the move yet... its a reasonable safety fallback mechanism.

It also turns out we use the watcher for balance and timelock updates. I'll keep the watcher and make it interact with the swap manager.

We could also bundle it with #932

Yes. Although there still should be an option to stop a swap from resuming without fully deleting it. It needs to be done as part of this PR though. Otherwise it gets really annoying for people in this situation of which there are a few.

@Einliterflasche I will merge this today.

We definitely need a docker test which spawns multiple swaps. Also get the ui mock system to work again, it's pretty broken now.

Also get the ui mock system to work again, it's pretty broken now.

Can you expand? It works perfectly fine for me.

• stale swaps still get shown on the Swaps tab even when I clicked "do not auto resume"
• I'd expect there to be one mock control ui thing for each swap, immediately as part of that swap widget. so that we can test multipe swaps at the same time, controlling each on it's own